GlobalPlatform technology defines the secure elements, for example in specification “GlobalPlatform Card Specification—Version 2.2.1”.
A Secure Element (SE) is known to be a tamper resistant component, possibly removable, which is used in a hosting device to provide the security, confidentiality, and multiple-application environment required to support various business models. A secure element may be compliant with the norm ISO/IEC 7918. An usual hosting device is a mobile phone.
Such a Secure Element may exist in any form factor such as UICC (standing for Universal Integrated Circuit Card), embedded SE, smartSD, smart microSD, etc.
A security mechanism therein, called Secure Element access control is used in addition to existing protection mechanisms (such as permissions or security OS policy limiting access to sensitive APIs). The access control is designed to prevent unauthorized access to resources in the Secure Elements and typically to prevent denial of services attacks (PIN blocking, selection of non multi-selectable applets, etc.).
This access control mechanism is transparent to client applications running in the device and is enforced within the hosting device operating system itself, generally by an Access Control Enforcer (ACE) forming part of the Secure Element access API.
GlobalPlatform standard entitled “Secure Element Access Control—version 1.0. specifies how the access policy is stored in the Secure Element, and how it can be accessed and applied by the hosting device.
According to the standard, an access control rule specifies that:                for a specific SE application, or for all other SE applications on a given SE,        a given device application or all other device applications have access rights to:                    all APDUs, no APDUs, or selected APDUs;            all NFC events or no NFC events, NFC standing for “Near Field Communication”.                        
The SE and device applications specified in the access control rule form the target or premises of the rule, while the access rights to APDUs and NFC events form the conclusion of the rule.
In operation, when a device application requests access to a SE application, a SE API (an API for device applications to interact with applications hosted by a Secure Element) invokes the Access Control Enforcer with the identifier (or DeviceAppID which is for example a hash of the device application code) of the device application requesting the access and the identifier (or AID) of the SE application to which the access is requested. Then, the Access Control Enforcer is in charge of retrieving (using for example a “GET DATA” command as defined in the above-mentioned standard) the Access Rules applicable for the corresponding device application and SE application. If the access is granted, the SE API access request is accepted and the device application is allowed to exchange commands (e.g. APDUs) with the SE application. If the access is not granted, the SE API request is rejected and the device application is not able to exchange commands (e.g. APDUs) with the SE application.
A schematic functional architecture of the hosting device and the Secure Element is shown in FIG. 1, which is taken from the above standard.
The Card Issuer and Application Providers define access control rules (or access rules) for the applications in their respective Security Domain, and supply (for example using a “STORE DATA” command as defined in the above-mentioned standard) to a respective Access Rule Application Client or Master (ARA-C or ARA-M).
The ARA-M (only one in the SE), which is associated with the Card Issuer Security Domain and managed by the Card Issuer (directly or with administration delegation to a remote server entitled Trusted Service Manager), is in charge of retrieving all available access rules after the SE receives a request from the Access Control enforcer on the device.
If necessary, the ARA-M may request (using, for example, a predetermined API interface, method or event) the ARA-Cs associated with the Application Provider Security Domains to retrieve rules stored in these ARA-Cs.
Because an access control rule may not only apply to an individual application, but also to multiple applications, and because separate rules may be defined in different places of the Secure Element (for example, in the ARA-M and in an ARA-C), access control rules may overlap and conflict.
Potential conflicts shall be avoided by the ARA implementation as much as possible. For example it may be provided that any ARA rejects provisioning/supplying of a new access control rule if a rule for the same target (AID and DeviceAppID) already exists in another ARA in the SE. In such a case the Service Provider shall be informed with a dedicated status word (‘6A 89’).
However, in scenarios it might happen that rules applying to the same target (AID and DeviceAppID) exist in the SE. This is for example the case if the rules are already pre-installed in an ARA and are available immediately after the ARA instantiation.
A rule-priority policy has been proposed in the standard to solve access control rule conflicts in the course of determining which rule to apply.
According to this policy, performed at the ARA-M or at the Access Control Enforcer, specific rules have priority over generic rules, wherein a specific access rule is a rule associating explicitly a DeviceAppID and an AID (the others are generic rules). Additionally, more restrictive rules have priority over less restrictive rules, wherein the most restrictive access rules are those that forbid access the device application to the SE application. In addition, access rules having the same priority may be aggregated as defined in the standard.